Fixes #2568.

Problem

Every kind:7 Buzz emits carries only the target e tag:

{"kind":7,"tags":[["e","8f8c92f8…"]],"content":"👍", …}

NIP-25 also requires the reacted-to author's p tag. That tag is not cosmetic — it is the only thing a notification feed can key on. Without it, {"kinds":[7],"#p":[<self>]} can never match, so a reaction to your message is invisible to every NIP-01 client, which is what @vitorpamplona hit from Amethyst.

It isn't only an interop gap. The relay already ships kind 7 as push-notifiable — PUSH_KINDS = &[7, 9, 1059, 40007, 46010] (crates/buzz-relay/src/handlers/push_lease.rs:15) — and the lease subscription shape is literally {"kinds":[7],"#p":[…]}. The push surface is built around a tag no Buzz client produces.

Four producers were affected: buzz-sdk, the desktop Tauri command, buzz-cli, and buzz-acp's 👀/💬 status reactions.

Solution

Thread the target author through every reaction producer.

buzz-sdk — build_reaction / build_custom_emoji_reaction take target_author: nostr::PublicKey and emit ["p", <author>]. Required rather than Option, so a caller can't silently reintroduce the non-conformant form.

Both builders now set .allow_self_tagging(). This is the subtle part: reacting to your own message makes the p tag match the signer, and nostr 0.44 strips matching p tags by default. Without it, self-reactions would quietly regress to the old wire form. The repo already relies on this for NIP-IA (build_archive_identity_request); the reaction path now does too, pinned by a regression test.

Desktop — add_reaction takes target_pubkey from the caller. The timeline already resolved it via resolveEventAuthorPubkey, so this uses the displayed author, not the raw signer. For relay-signed agent messages those differ, and the displayed author is who should be notified. Passing it in also avoids a second relay round trip on a hot UI path.

buzz-cli — only ever gets an event id, so it resolves the author with a kindless ids:[…] lookup. That filter shape is explicitly exempt from the #p read gate (req.rs:1061, "a kindless ids lookup is unaffected"). A target that doesn't resolve here would have been rejected by ingest anyway (invalid: reaction target event not found); failing early just gives a clearer message.

buzz-acp — the 👀/💬 indicators are reactions like any other, so they carry the tag too. The author is already on the batch event; react_working now takes (event_id, author) pairs. Removal is unchanged — a kind:5 delete keys off the reaction's own id, so ReactionGuard still only needs ids.

Tag order is e, p, emoji. Ingest resolves the reaction target from the last e tag (ingest.rs:2247), so adding a p tag cannot shift target resolution.

Why this is behaviour-neutral in-app

Worth stating explicitly, since "add a p tag" could plausibly mean "start waking agents on every 👍":

• The desktop feed queries kinds [9, 40002, 1, 45001, 45003] (commands/messages.rs:72) — no kind 7.
• Mobile's activity feed uses the same kind set (activity_provider.dart:33).
• The ACP mention subscription defaults to [KIND_STREAM_MESSAGE, KIND_WORKFLOW_APPROVAL_REQUESTED, KIND_STREAM_REMINDER] (config.rs:1157) — no kind 7, so p-tagged reactions do not wake agents.
• Kind 7 is not in P_GATED_KINDS, so no read path changes.

The only things that change are NIP-25 conformance on the wire and the relay's already-advertised push surface becoming reachable.

Validation

Toolchain note: this was built on Windows with the x86_64-pc-windows-gnu toolchain (no MSVC linker locally), so clippy is 1.97 rather than the pinned 1.95.

• cargo test -p buzz-sdk --lib — 234 passed, 0 failed, including the new reaction_keeps_p_tag_when_reacting_to_own_message. I verified that test has teeth: with .allow_self_tagging() removed it fails with assertion failed: has_tag(&ev, "p", …), confirming the nostr 0.44 scrub is real and not theoretical.
• cargo check -p buzz-sdk -p buzz-cli -p buzz-acp — clean.
• cargo fmt -p buzz-sdk -p buzz-cli -p buzz-acp -- --check — clean.
• cargo clippy -p buzz-sdk -p buzz-cli -p buzz-acp --all-targets -- -D warnings — the only findings are two pre-existing question_mark lints in crates/buzz-acp/src/queue.rs (313, 942), a file this PR does not touch; they come from the newer clippy, not from this change.
• cargo check on desktop/src-tauri — clean (24 pre-existing dead-code warnings in managed_agents/, none from this PR).
• pnpm typecheck and pnpm lint in desktop/ — both clean.
• biome format on the six changed TS files — clean. (Checked against LF copies; my checkout is core.autocrlf=true, which makes biome report all 1600 files unformatted locally.)
• Desktop JS unit tests could not run here: the loader crashes on Windows with ERR_UNSUPPORTED_ESM_URL_SCHEME … Received protocol 'c:' on a clean tree too. No test references add_reaction, so nothing in that suite covers this path either way.

The E2E mock (e2eBridge.ts) now emits the p tag as well, so inbox-reactions.spec.ts's "real add_reaction wire shape" assertion stays honest. It falls back to reading the author out of its own mock event store when a spec drives add_reaction directly without one, so the two existing specs that do that keep working unchanged.

Follow-up, not done here

NIP-25 also suggests a k tag carrying the target's kind, which helps clients filter reaction notifications. Every call site now has the target event in hand so it would be cheap, but it's a separate wire change and I kept this PR to the reported bug.